What’s Architecture Design
Terms
系统：泛指由一群有关联的个体组成，根据某种规则运作，能完成个别元件不能单独完成的工作的群体。
模块：划分的目的是职责分离。
组件：划分的目的是复用。
软件架构：软件系统的顶层结构。
- 系统由一群关联个体组成。
- 明确系统包含的个体，例如子系统、模块、组件等等。
- 明确个体运作和协作的规则。
Architecture Design Purpose
架构设计的目的：解决复杂度带来的问题。
复杂度的来源
- 高性能
- 高可用
- 可扩展性
- 低成本
- 安全
- 规模
常见误区
- 因为架构很重要，所以要做架构设计
- 不是每个系统都要做架构设计吗？
- 为了高性能、高可用、扩展，所以要做架构设计，上来就要实现”三高“，结果会出现架构设计无比复杂。
Difference between framework and architecture
框架关注的是规范，架构关注的是结构
Design Principle
- 合适原则
- 简单原则
- 演化原则
合适原则
宣言：合适优于业界领先。
脚踏实地做事
- 将军难打无兵之仗：没那么多人，却想干那么多活，是失败的第一个主要原因。
- 罗马不是一天建成的：没有那么多积累，却想一步登天，是失败的第二原因。
- 冰山下面才是关键：没有那么卓越的业务场景，却幻想灵光一闪成为天才，是失败的第三个主要原因。
简单原则
宣言：简单优于复杂
”复杂“在制造领域代表先进，在建筑领域代表领先，但在软件领域，却恰恰相反，代表的是”问题“。
软件领域的复杂性体现：
- 结构的复杂性
- 组件数量多
- 组件之间关系复杂
- 逻辑的复杂性
- 遵循KISS原则（Keep It Simple, Stupid!）
带来的问题：
- 组件越多，就越有可能其中某个组件出现故障，从而导致系统故障。
- 某个组件改动，会影响关联的所有组件，这些被影响的组件同样会继续递归影响更多组件。
- 定位一个复杂系统中的问题总是比简单系统更加困难。
演化原则
宣言：演化优于一步到位
Windows系统的发展历史，Android系统发展历史
对于软件来说，变化才是主题。软件架构需要根据业务的发展而不断变化。设计Windows和Android的人都是顶尖的天才，即便如此，他们也不可能在1985年设计出Win8，不可能在2009年设计出Android 6.0。
如果没有把握”软件架构需要根据业务发展不断变化“这个本质，在做架构设计的时候就会容易陷入一个误区：试图一步到位设计一个软件架构，期望不管业务如何变化，架构都稳如磐石。
生物演化：
- 生物要适应当时的环境。
- 生物需要不断地迭代繁殖，将有利的基因传承下去，将不利的基因剔除或修复。
- 当环境变化时，生物要能够快速改变以适应环境变化；如果生物无法调整就被自然淘汰；新的生物会保留一部分原来被淘汰的生物的基因
软件架构设计：
- 设计出来的架构要满足当时的业务需要。
- 架构要不断地在实际应用过程中迭代，保留优秀的设计，修复有缺陷的设计，改正错误的设计，去掉无用的设计，使得架构逐渐完善。
- 当业务发生变化时，架构要扩展、重构、甚至重写；代码也许会重写，但有价值的经验、教训、逻辑、设计等却可以在新架构延续。